Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d14/emag10.arc/EMAG10T.TXT

Text File | 1991-01-02 | 61KB | 1,366 lines

                 OnLine's Electronic Magazine (EMAG)
                              Issue #10

The tenth issue of OnLine's Electronic Magazine (EMAG) is available
for downloading in the Software Library. The file is EMAG10.ARC.
Microsoft has created this magazine to provide our OnLine customers
with information about the OnLine service, including techniques on how
to most effectively use the service. We also hope the magazine will
encourage you to send us feedback so that we can provide the best
possible service to you, our OnLine customers.

                          Table of Contents
                          -----------------

Word 5.50 Introduction.......................................EMAG10-1

Converting Word 5.00 Macros for Use in Word 5.50.............EMAG10-2

Word Version 5.50 Articles..............by Microsoft OnLine Personnel

(The information in these articles may also be found in the Knowledge
Base by searching on the appropriate Q number shown in parentheses).

   Word 5.50: Viewing List Box Contents Without a Mouse
   (Word, Q67191)............................................EMAG10-3

   Word 5.50: Installing Mouse Driver and Updating System
   (Word, Q66066)............................................EMAG10-4

   Word 5.50: New Command-Line Switches
   (Word, Q66133)............................................EMAG10-5

   Word 5.50 Freeing Up Memory When Shelling Out
   (Word, Q66065)............................................EMAG10-6

   Word 5.50: Setup Does Not Overwrite Word Version 4.00
   (Word, Q67157)............................................EMAG10-7

   Decompressing Word 5.50 Files with Setup
   (Word, Q64464)............................................EMAG10-8

   WORD.PIF Settings for Windows 3.00
   (Word, Q65737)............................................EMAG10-9


What's New.............................by Microsoft Support Personnel

(The information in these articles may also be found in the Knowledge
Base by searching on the appropriate Q number shown in parentheses).

   Accessing Program Segment Prefix in OS/2 Bound Program
   (OS/2 SDK, Q66821).......................................EMAG10-10

   COM/Serial Port Detection in OS/2
   (OS/2 SDK, Q66236).......................................EMAG10-11

   PM: Determining Which Button Is the Default or Focused Button
   (Presentation Manager, Q65966)...........................EMAG10-12

   Adding and Removing FCF_SIZEBORDER Style of a PM Frame Window
   (Presentation Manager, Q66464)...........................EMAG10-13

   Memory Requirements for Real-Mode CodeView (CV.EXE)
   (CodeView, Q66513).......................................EMAG10-14

   How to Add Other Language Compilers to PWB's Build Options
   (PWB, Q65568)............................................EMAG10-15

   What Happens to Stack Memory When Thread Terminates?
   (C Compiler, Q66295).....................................EMAG10-16

   Using _psp for Pointer Checking
   (C Compiler, Q66127).....................................EMAG10-17

   Differences/Enhancements from BASIC PDS 7.00 to 7.10
   (BASIC Compiler, Q65598).................................EMAG10-18

    How SUB and FUNCTION Windows Inherit DEFtype in QB.EXE Editor
   (QuickBASIC, Q47491).....................................EMAG10-19

   Description of Stub Files and How They May Enlarge EXE
   (BASIC Compiler, Q62908).................................EMAG10-20

   Which BASIC Versions Can CALL C, FORTRAN, Pascal, MASM
   (QuickBASIC, Q35965).....................................EMAG10-21

======================================================================
                               EMAG10-1
                        Word 5.50 Introduction
                          By Donna Inchinose

This new version of Microsoft Word has been designed with two major
goals in mind -- making the product easy to learn, as well as easy to
use. To accomplish these goals, Microsoft has changed the interface,
or the way Word looks, to a character window (CW) interface. The
advantages of this new interface are:

1. A new, more intuitive menu system that includes a menu bar along
   the top of the screen with pull down menus that allow you to see
   all the commands available to you. Each of the menu groups contains
   commands that are similar or related in function.

2. The ability to have up to 9 documents or style sheets open at one
   time in overlapping windows, or 10 windows if you count the help
   window.

3. Easy referral to Help, in a window that can remain open as you work
   on your document.

4. A formatting ribbon that will allow you to immediately see what
   font or font size your text is formatted for, as well as allow you
   to easily format your text for a font, font size, or paragraph
   style from your stylesheet.

5. Speed-formatting keys for character formats.

6. A flashing underscore, instead of a single selected character
   (block), as its cursor to mark the insertion point. This eliminates
   the need for applying character formatting twice when you are
   trying to format a single character.

The character window interface also follows a standard function key
assignment that is consistent with our other Word products, such as
Word for Windows and Word for the Macintosh. These function key
assignments differ from the key assignments in Word 5.00, but to
assist you in adjusting to this new interface if you are using Word
5.00, we have added the ability to retain the Word 5.00 function
assignments. You choose this option either when you run the Setup
program or by choosing the Customize dialog box from the Utilities
menu and checking the box next to "Use Word 5.0 Function Keys". The
functions of the DEL and INS keys are also different in the character
window interface, where INS and DEL will NOT insert from or delete to
the scrap. To retain the functionality of the INS and DEL keys
available with Word 5.00, you can uncheck the box next to "Use INS for
Overtype Key" in the Customize dialog box of the Utilities menu.

This new interface will also pose a few hurdles for Word 5.00 macros.
With the new interface, keystroke sequences to access Word's powerful
word processing features have changed. To assist you in updating your
Word 5.00 macros to run in Word 5.50, we have included the utility
MACROCNV.EXE. This macro converter is meant only as a tool to assist
you in converting your macros. Once you have converted macros with the
macro converter, it will be necessary for you to review and edit your
macros to optimize them to your exact needs. Please be aware that the
macro converter cannot convert 100 percent of the commands in your
macros.

For more information about what is new with Word, please refer to
Chapter 1 of the "Getting Started" pamphlet included with your Word
5.50 documentation.

======================================================================
                               EMAG10-2
           Converting Word 5.00 Macros for Use in Word 5.50
                          by Charlie Gifford

There are major differences between the Microsoft Word version 5.50
character windows interface and the Microsoft Word version 5.00
multitool interface. As a result, Word 5.00 macros converted by the
macro conversion utility, MACROCNV.EXE, may not run correctly in Word
5.50.

MACROCNV.EXE is a tool designed to help you convert Word 5.00 macros
for use in Word 5.50. Some Word 5.00 macros may convert incorrectly or
contain unnecessary commands that require editing before the macro is
run in Word 5.50. After conversion, all macros should be executed with
a test document. Be sure to make backup copies of any documents that
are to be modified by a newly converted macro.

The macro converter creates a backup copy of your Word 5.00 glossary
files by renaming the Word 5.00 glossary with a "GL5" extension.

Converted macros can be edited with the Word 5.50 Macro Edit command.

Limitations and/or Potential Problems with the Macro Converter
--------------------------------------------------------------

Speed keys (used to invoke the macro) assigned to Word 5.00 macros,
may conflict with Word 5.50 built-in speed keys. Changing the speed
keys that are assigned in the converted macro, or using CTRL+A before
pressing the speed-key combination will solve this problem. If you
have assigned the speed-key combination CTRL+A to a Word 5.00 macro,
you should change this key combination to something new before running
the converted macro in Word 5.50.

Macros that use the F1 key to display a list of files in Word 5.00
will be converted so that the macro will pause and allow you to select
a file from a files list box.

Written or recorded macros that assume certain Word 5.00 menu settings
will not convert correctly. The most common macro instruction that
poses a problem for the macro converter is a recorded macro that
selects menu options with the SPACEBAR, instead of the first letter of
the menu option.

"Run time" decisions made by Word while the macro is running may not
convert correctly. For example, the ENTER key will be interpreted
differently if Word is spell checking, in the Thesaurus or Gallery, or
in the document view. There is no way for the macro converter to tell
whether ENTER means to check the spelling of the next word, insert a
paragraph mark in the document, or carry out a menu command. In the
Word 5.00 Gallery, if you choose to format a style, Word recognizes at
run time whether it is a character, paragraph, or section format and
takes you to the appropriate menu. There is no way for the macro
converter to identify the type of format chosen. Another run time
decision is made with macros that set the promptmode variable to Yes.
There is no way to determine the user's response to the prompt and
guarantee a value for a macro variable.

If a Word 5.00 macro changes several fields in one command menu, the
Word 5.50 macro may have to choose more than one menu to make the same
changes. For example, settings that can be accessed through the Word
5.00 Options menu may now require the macro to choose the Word 5.50
View and Utilities menus.

Macro translation may be further complicated if you must press ENTER
or ESC to leave a dialog box in Word 5.00. If the macro converter adds
an ENTER-key press, additional options in Word 5.50 may be carried out
unintentionally. If the macro converter adds ESC to a macro, options
set in a dialog box may be canceled. Word 5.00 commands that may cause
problems similar to these include Format Division Margins, Search,
Replace, Options, and Print Options.

Word 5.00 macros that involve moving, splitting, or sizing windows,
and moving from window to window may not convert properly. Because of
Word 5.50's support of overlapping windows, the Window Split
Horizontal and Window Split Vertical commands are not valid for Word
5.50 and are ignored by the macro converter.

The following Word 5.00 macro actions may not convert properly:
selecting Library Document-Retrieval and changing the pathname, and
using Transfer Allsave when glossaries, style sheets, or unnamed
documents have not been saved.

Macros containing nested macros and conditional statements may not be
converted correctly. Most macros containing nested macros can be
successfully converted if the macro is called from edit mode. If a
function key is used to call a macro, the macro converter assumes that
a built-in function is being used. The macro converter is restricted
to one level of IF statements; nested IF statements cannot be
converted.

Workarounds
-----------

If you edit a macro and still encounter problems executing the
converted macro, you may want to consider recording the macro in Word
5.50. This may save you time in the long run.

If you encounter problems converting a Word 5.00 macro, you can load
your Word 5.50 document into Word 5.00, run your old macro in Word
5.00 on your Word 5.50 document, then load your modified document back
into Word 5.50. This may be helpful if you are under a deadline to
finish a document and don't have the time to edit the converted macro
right away.

======================================================================
                          Word Version 5.50
                by Microsoft Product Support Personnel

                               EMAG10-3
         Word 5.50: Viewing List Box Contents Without a Mouse
                            (Word, Q67191)

To view the contents of a drop down list box without the use of a
mouse, do the following:

Select the contents of the field and hold down the ALT key and press
the DOWN ARROW key (ALT+DOWN ARROW). This will display a list of
options available to this field.

Example 1
---------

To view the list of available fonts in the Format Character dialog
box:

1. From the Format menu, choose Character (ALT, T, C).

2. Hold down the ALT key and press the DOWN ARROW key (ALT+DOWN
   ARROW).

A list of available fonts will now appear in a drop down list box.

Example 2
---------

To view the list of available fonts from the ribbon:

1. Activate the ribbon (if not active) with ALT+V+B.

2. Hold down the CTRL key and press the F key (CTRL+F).

3. Hold down the ALT key and press the DOWN ARROW key (ALT+DOWN
   ARROW).

A list of available fonts will now appear in a drop down list box.

======================================================================
                               EMAG10-4
        Word 5.50: Installing Mouse Driver and Updating System
                            (Word, Q66066)

When running the Word 5.50 Setup program for a DOS-based computer
system with a mouse pointing device, select the "Update the mouse
driver" and "Update the system files" options to ensure that the
updated mouse driver is installed properly.

If the "Update the mouse driver" option is selected and the option to
"Update the system files" is not selected, the Setup program will only
copy the updated mouse driver (MOUSE.SYS) to the Word program
directory and not add the necessary device line to the CONFIG.SYS file
to use the new mouse driver.

To add the device line to the CONFIG.SYS file, the Setup program can
be run with the option to "Modify an existing version of Word." Choose
to "Install a mouse" and have the Setup program modify the system
files. (You can also manually add a line to the CONFIG.SYS file to
include the path to the updated MOUSE.SYS file, that is,
device=c:\mouse.sys).

If the mouse being used is not a Microsoft or IBM PS/2-compatible
mouse, it is strongly suggested that the manufacturer's mouse driver
be used. If there are problems relating to a manufacturer's mouse in
Word, contact the manufacturer of the mouse regarding a possible
updated mouse driver to use with Microsoft Word version 5.50.

Microsoft System Diagnostics can be used to determine the mouse driver
version that is being loaded on startup.

======================================================================
                               EMAG10-5
                 Word 5.50: New Command-Line Switches
                            (Word, Q66133)

The following is a list of new command-line switches for Microsoft
Word version 5.50. To use any of the following switches, type "word
/(switch)" at the command prompt (for example, "word /z"):

   Switch              Function
   ------              --------

   /i                  Turns cursor blinking off in graphics mode.
   /m (macroname)      Loads a macro from NORMAL.GLY automatically on
                       startup.
   /p                  Uses Word 5.50 function keys and uses INS to
                       toggle Overtype.
   /t                  Uses Word 5.00 function keys and uses INS to
                       insert text from scrap.
   /w                  Ignores line spacing at the top of a page so
                       that when the last line in the window is
                       reached, Word wraps text to the top of a new
                       window and starts a new line.
   /z                  Returns all switches back to the Word 5.50
                       defaults.

Additional switches available in previous versions of Microsoft Word
and Word version 5.50:

   Switch              Function
   ------              --------

   /bn                 Specifies the number of internal page buffers
   for
                       expanded memory (number between 4 and 1500).
   /k                  Disables an enhanced keyboard.
   /l                  Opens the last document edited during the last
                       Word session.
   /n                  For use with a Novell network.
   /x                  Disables expanded memory.
   /y                  Enables Word 4.00 scrolling.

======================================================================
                               EMAG10-6
            Word 5.50 Freeing Up Memory When Shelling Out
                            (Word, Q66065)

When selecting DOS commands or OS/2 commands from the File menu in
Microsoft Word version 5.50, include the extension of the program to
run from the operating system shell (for example, COMMAND.COM instead
of COMMAND) in order to free up memory. If the file extension (.COM,
.EXE) is included, Word will throw away its page buffers and close any
open files, making more memory and file handles available to programs
executed from the operating system shell.

Because Word 5.50 will close any open files if the file extension is
included, you must be careful not to modify any files that will be
reopened by Word when the operating system shell is exited and control
is returned to Word. If a file is modified, Word may be unable to
continue or the file may become corrupted.

Page buffers are 512-byte blocks of memory that contain document text.
The number of page buffers created by Word is determined by the amount
of memory available. If no expanded memory is available, the size of
the page buffers cannot exceed 64K. When Word throws away its page
buffers to execute an operating system shell, approximately 50K of
memory will be freed.

File handles are 16-bit numbers that the operating system uses to
identify open files and/or to identify other input/output sources for
a program. The default internal data structure for DOS only allows for
eight file handles. The number of file handles can be increased with
the use of the FILES command in the CONFIG.SYS file (for example,
Files=20).

======================================================================
                               EMAG10-7
        Word 5.50: Setup Does Not Overwrite Word Version 4.00
                            (Word, Q67157)

The Setup program for Microsoft Word version 5.50 will not overwrite
an existing installation of Word version 4.00 or earlier.

If a previous version of Word (version 4.00 or earlier) exists in the
same subdirectory that Word version 5.50 is installed in (for example,
C:\WORD), the program files of the previous version are not
overwritten.

To manually remove the previous version of Word, delete or rename the
WORD.COM and WORD.PGM files from the Word program directory. This will
not affect the Word version 5.50 installation because the Word version
5.50 executable file is WORD.EXE.

The "Install a new version of Word" option in the Word 5.50 Setup
program only overwrites the Word version 5.00 program file (WORD.EXE).

======================================================================

                               EMAG10-8
               Decompressing Word 5.50 Files with Setup
                            (Word, Q64464)

The majority of the files on the Word 5.50 disks are compressed, and
can be distinguished from the uncompressed files on disk by the dollar
sign ($) that occupies the last character position in the file
extension.

The Setup program will automatically decompress a compressed file when
it copies the file to disk during the installation of Word 5.50. Setup
can also be used to decompress a file, using the following command
syntax:

   SETUP /d [source file] [destination file]

Setup must be able to locate the WORD55.INF and PRD.INF installation
information files in the directory from which it is invoked. If these
files cannot be found, Setup will display the message "Information
file is not in current directory" and will not properly decompress the
file.

If no destination file is specified when Setup is invoked, Setup will
create an uncompressed file on disk with the name that is stored in
the compressed file's header.

======================================================================
                               EMAG10-9
                  WORD.PIF Settings for Windows 3.00
                            (Word, 65737)

Microsoft Word version 5.50 includes a Program Information File (PIF)
called WORD.PIF for use with Microsoft Windows version 3.00. Because
Word 5.50 is a non-Windows application, it is strongly recommended
that Word 5.50 be started from WORD.PIF when running Word from Windows
3.00.

To set up Word 5.50 to run from the Windows 3.00 "Non-Windows
Applications" group using WORD.PIF, follow these steps:

1. From the Window menu of the Windows 3.00 Program Manager choose
   "Non-Windows Applications" (another group name may be substituted).

2. From File menu of Program Manager, select New.

3. Select Program Item, and click OK or press ENTER.

4. The Program Item Properties screen will appear.

   Beside the Description field, type "Word 5.50". The contents of the
   Description field are optional. The description text that is
   entered will appear under the icon associated with the Word 5.50
   program item.

   Beside the Command Line field, type the drive and directory path to
   the location of WORD.PIF (for example, C:\WORD\WORD.PIF).

5. Select OK.

   A new program item icon will appear in the active group (Non-
   Windows Applications). Word can now be started from Windows by
   double-clicking the new icon.

WORD.PIF settings (for use with Windows 3.00) are as follows:

   Program Filename:        WORD.EXE
   Window Title:            Microsoft Word 5.5
   Optional Parameters:     None
   Start-up Directory:      None
   Memory Requirements:     KB Required: 384
                            KB Desired:  640
   Display Usage:           Full Screen
   Execution:               Exclusive
   Close Window on Exit:    Yes

Note: SETUP.EXE does not modify the WORD.PIF settings to reflect any
options selected or specified during installation.

The Windows 3.00 PIF Editor can be used to customize the WORD.PIF
included with Word 5.50. Use the Start-Up Directory and Optional
Parameters fields to customize the WORD.PIF file. Changing the memory
requirements in the KB Required field to a value less than 384 KB
(kilobytes) is not recommended.

The following are Advanced Options (available under 386 enhanced mode
only):

   Multitasking Options:    Background Priority: 50
                            Foreground Priority: 100
                            Detect Idle Time:    Yes
   Memory Options:

   EMS Memory:              KB Required: 0  KB Limit: 1024  Locked: No
   XMS Memory:              KB Required: 0  KB Limit: 1024  Locked: No
   Uses High Memory Area:    Yes (checked)
   Lock Application Memory: No (unchecked)
   Display Options:         Video memory: High Graphics
   Monitor Ports:           Text (checked), Low Graphics (checked)
   Emulate Text Mode:       Yes (checked)
   Retain Video Memory:     Yes (checked)

Note: Word 5.50 can access expanded memory (EMS) that meets the Lotus-
Intel-Microsoft (LIM) specification versions 3.20 or later. To allow
Word to access expanded memory when running under Windows 386 enhanced
mode, indicate a value (other than zero) in the Advance Options, EMS
Memory (KB Required) section of the PIF file. Word 5.50 does not use
extended memory (XMS).

The following are other options:

   Allow Fast Paste:        No (unchecked)
   Allow Close When active: No (unchecked)
   Reserve Shortcut Keys:
                            ALT+TAB:     No (unchecked)
                            PRTSC:       No (unchecked)
                            ALT+ENTER:   No (unchecked)
                            ALT+ESC:     No (unchecked)
                            ALT+PRTSC:   No (unchecked)
                            CTRL+ESC:    No (unchecked)
                            ALT+SPACE:   Yes (checked)

Application Shortcut Key: None

======================================================================
                              What's New
                by Microsoft Product Support Personnel

                              EMAG10-10
        Accessing Program Segment Prefix in OS/2 Bound Program
                          (OS/2 SDK, Q66821)

Question:

I have a bound application program that runs in OS/2 and MS-DOS. This
program is a type of "shell" that spawns other programs. However, in
MS-DOS, the shell takes up too much memory to run large programs, such
as the Microsoft C Compiler version 6.00. Therefore, I am interested
in using the do_exec and do_spawn functions that were presented in the
article by Marc Adler in the September 1990 issue of the "Microsoft
Systems Journal," titled "Spawn Programs from Within Your DOS
Application Using Almost No Additional Memory."

I have downloaded the source code and examined it. It uses some C run-
time functions such as INTDOS and INTDOSX that are not in the
protected mode versions of the C run-time libraries. This is no
problem because I can substitute FAPI calls for them to get the
information they need. However, the SPAWN.ASM module needs to access
the program segment prefix (PSP), and it tries to get the PSP's
address by referencing the external variable _psp. This variable is
not defined in the protected mode C run-time libraries. I assume that
it was omitted because protected mode programs running in OS/2 really
have no need to access the PSP. What about a bound version of the
program running in MS-DOS? Is the PSP the same, and if it is, is there
any way a bound program can access it (perhaps through a register)?

Will the technique used in the do_spawn function to swap programs in
MS-DOS work at all for a bound program? If it will work, how should I
adapt the code?

Response:

You are correct that the run-time library global variable _psp has
been removed from the protected mode run-time libraries; OS/2 programs
do not have a PSP. However, a bound program does construct a PSP for
compatibility with older MS-DOS programs; you just don't have a _psp
to use to get to it.

However, you can call MS-DOS interrupt 0x21 function 0x51 to get the
address of your PSP when you are running a bound program in real mode
or under MS-DOS. If you put 0x51 into AH and call INT 21, the segment
of your PSP is returned in BX. The offset of the PSP into that segment
is 0 (zero). Be sure to call DosGetMachineMode() before calling this
interrupt. You cannot call this interrupt while running in protected
mode.

The following is a small sample program that shows how to access the
PSP using this interrupt in a bound program:

    #define INCL_DOSMISC
    #include <os2.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <dos.h>
    #include <memory.h>

    main()
    {
      BYTE bMachineMode;
      USHORT usPspSeg;

      if (DosGetMachineMode(&bMachineMode))
        {
        puts("error in DosGetMachineMode()");
        exit(1);
        }
      if (bMachineMode == MODE_REAL)
        {
        _asm
          {
          mov ah, 51h
          int 21h
          mov usPspSeg, bx
          }
        printf("PSP = 0x%04x\n", usPspSeg);
        }
      return(0);
    }

======================================================================
                              EMAG10-11
                  COM/Serial Port Detection in OS/2
                          (OS/2 SDK, Q66236)

Question:

Is it possible to determine if a physical COM board is installed for a
given COM/serial port? I have a program that requests, and is granted,
access to read/write to COM2 (0x2f8 -> 0x2f2) via the DosPortAccess()
function. Access is granted, but on some machines (not all), if a COM2
port is not physically installed, a protection fault is produced.

Response:

It is possible to do this, but you shouldn't use the DosPortAccess()
function. DosPortAccess() is essentially an NOP that always returns
success. It has been abandoned in OS/2 version 2.00.

One of the easiest ways to detect if a COM port is present is to try
to open the port using the DosOpen() function. By checking the return
code value, you should be able to detect whether the hardware is
present.

Another more difficult method is to actually write to the port
registers and read back the expected results. This involves setting up
IOPL segments in your application. This method is supported in OS/2
versions 1.10 and 1.21.

For more information, please refer to Chapter 14 of "Advanced OS/2
Programming" by Ray Duncan. This will help you set up the segments
properly. You then must decide which register you want to write to. On
an 8250, there is a scratch register that is safe to read and write
to. For COM2, the I/O address is 0x2FF. It is always the last register
you can write to, 0xXXF. The 8250 is probably the most common chip
used for COM ports on PCs. However, it is starting to be replaced by
16450s and 16550s.

======================================================================
                              EMAG10-12
    PM: Determining Which Button Is the Default or Focused Button
                    (Presentation Manager, Q65966)

Question:

In my dialog box, I have some entry fields and some buttons. By using
the TAB key, I can navigate through entry fields and buttons. When I
come to a button, the button gets the focus (a dotted-line cursor is
inside) and the button becomes the default (a heavy dark border is
displayed).

I have some buttons that I do not want to ever become the default
buttons -- just focused (that is, callable with the SPACEBAR key and
not with the ENTER key).

How can I disallow buttons from becoming the default button? Also, how
can I query the dialog box to find out which button is the default or
focused button?

Response:

The message you should be concerned with is BM_SETDEFAULT. This
message is sent to a button when that button is about to become the
default button.

You can disallow buttons from becoming the default button by
subclassing the button. Send most messages through to the old button
window procedure. However, screen out the BM_SETDEFAULT message. If
this message does not get through to the old window procedure, then
the button will not become the default.

Simply subclassing one button in order to cause it to refuse accepting
the default will result in a situation in which no button has the
default. For this reason, you may want to send this same message to
some other button at the time your button screens it out.

A button that has the default has the BS_DEFAULT style bit turned on.
You may get all of the style bits for any window by using
WinQueryWindowULong(., QWL_SYTLE). Obviously, you will have to step
through and check each one of the button HWNDs.

The best way to determine focus is by using the WinQueryFocus() call.
This method is different from the above method in that only one call
is required, and the result you receive will not necessarily be an
HWND in your own application.

======================================================================
                              EMAG10-13
    Adding and Removing FCF_SIZEBORDER Style of a PM Frame Window
                    (Presentation Manager, Q66464)

Question:

How can I update the frame controls of a window already on the screen?
Also, how can I obtain the frame-style bits so that I can change from
a size border to no border, and vice versa?

Response:

You need to change the style bits and send a WM_UPDATEFRAME message to
the frame.

Adding or removing the size border from a frame window is a little
different from adding or removing other frame controls. This is
because the size border is not a window. Therefore, you do not need to
destroy any windows, as you would if you were to remove the MINMAX
button.

The following is the code you need to add to perform this type of
functionality:

        ; Remove the size border.
        WinSetWindowBits( hwndFrame, QWL_STYLE, ~FS_SIZEBORDER,
                          FS_SIZEBORDER );
        WinSendMsg( hwndFrame, WM_UPDATEFRAME,
                    MPFROM2SHORT( FCF_SIZEBORDER, 0 ), 0L );

        ; Add the size border.
        WinSetWindowBits( hwndFrame, QWL_STYLE, FS_SIZEBORDER,
                          FS_SIZEBORDER );
        WinSendMsg( hwndFrame, WM_UPDATEFRAME,
                    MPFROM2SHORT( FCF_SIZEBORDER, 0 ), 0L );

======================================================================
                              EMAG10-14
         Memory Requirements for Real-Mode CodeView (CV.EXE)
                          (CodeView, Q66513)

Real-mode versions of CodeView (CV) beginning with version 3.00 offer
a number of ways to utilize available memory in order to make the
greatest amount of conventional memory available to the program being
debugged. The amount of memory actually used depends on the command-
line options specified as well as the configuration of the system used
for debugging.

The following table shows the size of CodeView in standard DOS memory
with each of the memory-specific command-line options (see below for
further details):

   Option  RAM Usage                   Option  RAM Usage
   ------  ---------                   ------  ---------

   /X       16K                       /D16     210K
   /E      192K                       /D32     225K
   /D      256K (same as /D64)        /D128    320K

The following descriptions of the three memory-related CodeView
options explain the ways in which each option affects memory
utilization in addition to the respective amounts of conventional
memory that CodeView requires with each. (This information pertains
only to CodeView versions 3.00 and later -- versions of CodeView
earlier than 3.00 require approximately 230K of RAM specifically for
CodeView.)

/X - Specifies that CodeView should utilize extended memory. Assuming
    that enough extended memory is available, this option moves both
    the symbolic information and most of CV itself into extended
    memory. Allowing CV to be loaded into high memory requires that
    approximately 16K to 19K of "control" code remain in conventional
    memory; thus all free conventional RAM over 19K is available to
    load the program to be debugged (the "debuggee").

/E - Specifies that CodeView should utilize expanded memory. Assuming
    that enough expanded memory is available, this option moves both
    the symbolic information and CodeView's own overlays into expanded
    memory. The size of the CV "root" without the extra overlayed code
    is approximately 192K. Since the overlays do not cause any
    additional overhead with /E, all free conventional RAM over 192K
    is available to load the debuggee.

/D - Specifies that CodeView should utilize disk overlays in
    conventional memory. By default, this option creates a 64K buffer
    area for loading disk overlays. With the 192K root, the 64K buffer
    means CV will take about 256K of conventional memory with /D. In
    addition, the symbolic information must also be loaded into
    conventional memory; therefore, since symbolic data varies with
    each program, it is not possible to specify the amount of memory
    available for the debuggee alone.

    The /D option can also be specified with a value that indicates
    the size of the overlay buffer area. This parameter can be any
    value from 16 to 128, which represents an overlay buffer size from
    16K to 128K. Specifying /D16 will minimize CodeView's size with
    disk overlays to approximately 210K. This maximizes the amount of
    conventional memory that will be available to load the debuggee
    and the symbolic information. At the other extreme, /D128 causes
    CV to use approximately 320K of conventional RAM. This provides
    faster CodeView execution speed, but it will only work with
    smaller debuggees.

Note: CodeView will default to the best memory usage possible. In
other words, if NO memory usage option is specified, CV will try to
use extended memory. If extended memory is unavailable, CV looks for
expanded memory. CV will use disk overlays on its own only if expanded
memory is not found.

======================================================================
                              EMAG10-15
      How to Add Other Language Compilers to PWB's Build Options
                            (PWB, Q65568)

The Programmer's WorkBench (PWB) is an environment capable of
utilizing different compilers for mixed-language programming. When
installed during BASIC version 7.10 setup, PWB version 1.10 shows
build options for the BASIC language only. However, it is possible to
include other language compilers to utilize the full features of the
PWB utility.

The following information applies to the Programmer's WorkBench
version 1.10 utility supplied with Microsoft BASIC Professional
Development System (PDS) version 7.10 for MS-DOS and MS OS/2.

Note that the 1.00 version of PWB is shipped with Microsoft C
Professional Development System (PDS) version 6.00. The steps below
should also apply to PWB version 1.00.

The Programmer's WorkBench (PWB.EXE) is an advanced development
environment capable of integrating several language compilers,
NMAKE.EXE, LINK.EXE, and the CodeView debugger. It offers the ability
to accomplish tasks, such as program development under protected mode
and mixed-language programming. This ability is not available in the
QuickBASIC extended development environment (QBX.EXE).

Two special files, PWBC.PX$ (for protected mode OS/2) and PWBC.MX$
(for DOS mode), reside on the BASIC PDS 7.10 disks and support the
option of using the C compiler in PWB. Since SETUP.EXE (in BASIC PDS
7.10) does not copy PWBC.PX$ and PWBC.MX$ during installation, these
files must be unpacked and transferred to your machine; for example,
to the \BINP subdirectory located in the \BC7 directory. (Note: The
UNPACK.EXE utility is found on disk 1 of the BASIC PDS package.) After
unpacking, the files will have the names PWBC.PXT and PWBC.MXT.

Next, the following command lines must be added to the TOOLS.INI file
to make the C compiler available to PWB:

   [pwb - .BAS .BI]
      LOAD: LogicalDrive:\[Path]\PWBC.PXT

For further information about installing PWBC.PXT and PWBC.MXT, see
page 54 of the "Microsoft BASIC 7.1: Getting Started" manual.

If you want to program in languages other than BASIC or C (such as
Microsoft Macro Assembler [MASM], Microsoft Pascal, Microsoft FORTRAN,
or Microsoft COBOL 3.00/3.00a), the following steps will insert the
initial build options to include other languages in PWB's build
options menu. In the example below, options to include the MASM.EXE
assembler are specified. If some other language's compiler is desired,
substitute appropriate changes for that compiler, where noted in the
specified areas.

 1. In PWB, go to the Options menu and select Build Options.

 2. Choose Save Current Build Options.

 3. Enter a meaningful message, such as "Options to Include MASM" in
    the window's edit field (if some other language is desired, change
    MASM to the appropriate name). Select the OK button from the Save
    Current Build Options and Build Options windows.

 4. Open the TOOLS.INI file in the PWB utility and go down to the
    bottom of the file. Somewhere near the bottom should be the tag
    "[PWB-Build Options: Options to Include MASM]" (or the language
    that was specified).

 5. In this section, add the following NMAKE instructions:

       build: inference .asm.obj masm_asm_obj
       build: command masm_asm_obj "masm $<;"

    Note: For languages other than MASM, distinguish a variable name in
    the inference rule to be used in the commands line (like
    masm_asm_obj has been used above) and then specify the appropriate
    compiler in the commands line within the quotation marks. The
    special filename macro specified in the quotation marks, "$<",
    applies the command to any object that has an out-of-date
    executable file.

 6. Press SHIFT+F8 to reinitialize the file; and then close it.

 7. Go to the File menu and select New (it is a good idea to close any
    lsfiles that are currently open before doing this step).

 8. Go to the Options menu and select Build Options.

 9. Choose Initial Build Options.

10. Select the "Options to Include MASM" option (it should be near the
    bottom of the list).

After completing these instructions, the PWB utility will now be ready
to compile assembler along with BASIC source code, provided that paths
to the necessary compilers are furnished.

======================================================================
                              EMAG10-16
         What Happens to Stack Memory When Thread Terminates?
                         (C Compiler, Q66295)

Question:

If I call _beginthread() with NULL as the second parameter, the run
time is supposed to create a thread stack for me. How is this done?
Also, when the thread terminates with _endthread(), is the memory
automatically released back to the operating system?

Response:

If _beginthread() is called with NULL for the thread stack, a stack of
size stack_size (passed as the third parameter) is malloc()'ed from
the heap. At the time the thread is terminated, the stack is still in
use; therefore, _endthread() does not automatically free it. In fact,
the last things _endthread() does are to push the appropriate
arguments onto the stack and call DosExit().

However, the memory is recovered. The next time that thread ID is
used, _beginthread() will check to see if the thread stack was
previously malloc()'ed internally by the function. If so, it will call
free() at that time. Note that the thread memory doesn't go to the
operating system; instead, it is returned to the heap. Due to the fact
that OS/2 will use a thread ID from terminated threads first, there
will usually be only one thread stack not free()'ed.

As a side note, in 32-bit OS/2, this is all a moot point. The 32-bit
DosCreateThread() API call will automatically allocate/deallocate the
thread stack.

======================================================================
                              EMAG10-17
                   Using _psp for Pointer Checking
                         (C Compiler, Q66127)

Problem:

I want to implement my own pointer checking routine. If the PSP
(program segment prefix) is set up in the lowest segment of available
memory, then I should be able to use _psp as the lower bounds for
legal pointer segments. However, if I write a program that compares
_psp with pointer segments returned by malloc(), I get back segment
values less than _psp.

Response:

When DOS loads an .EXE or .COM file, the PSP is set up in the lowest
segment of the largest contiguous block of available memory. There may
be other blocks of available memory below the location of the PSP;
however these blocks of memory are usually fairly small. If DOS
returns one of these segments, when pointer checking is implemented
with the /Zr option (available only with the /qc compiler option), the
segment is simply discarded and DOS is called again. This process is
repeated until a segment value greater than _psp is returned.

You can implement a similar routine in any C program by making calls
to a function, as demonstrated below, rather than making calls
directly to malloc(). However, the start-up code still will make calls
to malloc() directly for environment and argument space. Thus, the
pointer segments for the environment and arguments may still be less
than _psp. Further, it should be noted that this routine does not
implement pointer checking; it only enables programmers to implement
their own pointer checking by comparing segment values against _psp.

Another method of getting only pointer segments greater than _psp is
to modify the start-up code so that the value of _psp is stored at
_aseglo. This is the actual location used to store the lower segment
limit when pointer checking is implemented. The code to check the
segment returned by DOS against this location, and to call DOS again
if necessary, is already implemented. If it is necessary to have
pointer segments for the environment and argument variables greater
than _psp, a similar assignment can be used to modify the start-up
code. If this assignment is done before the space for these variables
is allocated in the start-up code, they will have segment values
greater than _psp. However, you should be aware that Microsoft can
make no guarantees about the implementation of this feature in any
future releases.

If a call to malloc() requires a new segment to be allocated from the
operating system, the call to DOS will be made requesting only the
amount of memory required by the malloc(). In subsequent calls,
requests are made for 8K blocks of memory until no more memory is
available from that segment. Since the blocks of memory below the PSP
are small, they may not be allocated during the first calls to
malloc(). Thus, you cannot be sure exactly when these blocks of memory
will be allocated.

Code Example
------------

void * _new_malloc (size_t size)
  {
  void * temp_ptr;
  temp_ptr= malloc (size);
  while ((temp_ptr != NULL) && (FP_SEG(temp_ptr) < _psp))
    temp_ptr= malloc (size);
  return temp_ptr;
  }

======================================================================
                              EMAG10-18
         Differences/Enhancements from BASIC PDS 7.00 to 7.10
                       (BASIC Compiler, Q65598)

In August 1990, Microsoft released the Microsoft BASIC Professional
Development System (PDS) version 7.10 for MS-DOS and MS OS/2 systems.
This article documents those features that were added to BASIC PDS
7.10 that are not supported in BASIC PDS 7.00. The lists below are
titled "Language Enhancements," "New Utilities and Utility
Improvements," and "Software Corrections."

This information applies to Microsoft BASIC Professional Development
System version 7.10 for MS-DOS and MS OS/2.

Language Enhancements
---------------------

1. REDIM PRESERVE changes the upper bounds (top-right dimension) of a
   $DYNAMIC array and preserves the data in the array. Previous
   versions of BASIC initialized the array to zeroes or null strings
   on a REDIM.

2. It is now possible to pass fixed-length-string arrays as parameters
   to SUB and FUNCTION procedures.

3. A CALL by value using BYVAL for BASIC SUB and FUNCTION subprograms
   is now possible. Previously, BASIC only supported CALL by value
   using BYVAL when calling a non-BASIC language such as C. The BYVAL
   attribute for passed parameters is now allowed when calling a BASIC
   SUB or FUNCTION.

4. ISAM is now supported under OS/2. ISAM in PDS 7.10 can be used in
   OS/2 protected mode. (Note that ISAM in PDS 7.10 is still single-
   user ISAM as in 7.00.)

5. ISAM support in 7.10 operates up to 50 percent faster than in 7.00,
   depending on the program.

6. Communications input is buffered during a SHELL if the program was
   compiled with the BC /O (stand alone) option. All previous versions
   of BASIC disabled communications support and buffering of
   communications data during a SHELL. BASIC PDS 7.10 does not,
   however, buffer communications data during a SHELL if you are using
   the run-time module (BRT71xxx.EXE).

7. BASIC PDS 7.10 now allows interlanguage calling to functions
   created with Microsoft C Compiler version 6.00. (BASIC PDS 7.00
   only allowed calling to Microsoft C Compiler version 5.10
   functions.)

New Utilities and Utility Improvements
--------------------------------------

1. QBX.EXE improvement: The 7.10 QuickBASIC extended (QBX.EXE)
   environment uses expanded memory more efficiently than 7.00. In
   BASIC PDS 7.00, each subprogram from 1K to 16K in size uses a full
   16K of expanded memory. In BASIC PDS 7.10, subprograms smaller than
   16K will use expanded memory in 1K chunks. In 7.10, if a subprogram
   is 2K in size, it will use only 2K of expanded memory. (Subprograms
   larger than 16K are stored in conventional memory in both 7.00 and
   7.10.)

2. Programmer's WorkBench (PWB), a new utility: The Programmer's
   WorkBench is the integrated development environment that is
   provided with Microsoft's newest "high-end" language products. It
   integrates the following features:

   -  Keyboard-driven or mouse-driven control of the WorkBench through
      use of menus and scroll bars.

   -  Ability to launch other utilities from PWB, such as NMAKE or
      CodeView.

   -  Context sensitive online Help.

   -  Multiple windows for managing multiple files for large projects.

   -  Multiple-language development within PWB.

   -  Supports development under both DOS and OS/2.

   -  Customizable program editor.

   -  Combines Microsoft's Quick environments (such as QuickBASIC and
      QuickC) and the Microsoft Editor, providing easier learning for
      anyone familiar with those environments. However, PWB offers
      many features over and above the Quick environments and the
      earlier Microsoft Editor.

3. Source Browser: Source Browser is a powerful cross-referencing tool
   that can be launched from within PWB.

4. The CodeView 3.10 debugger is included.

5. NMAKE facility: A superset of the earlier Microsoft MAKE facility.
   PWB saves you the inconvenience of remembering makefile syntax by
   building and maintaining makefiles for you.

6. QuickHelp: QuickHelp allows you to access online documentation
   without running QBX.EXE or PWB.EXE. QuickHelp can be run from the
   DOS or OS/2 command line and can also be installed as a keyboard
   monitor under OS/2. Any Help files with the correct format can be
   used with QuickHelp.

7. QBX.EXE improvement: In the QBX environment under the Run menu, the
   Make .EXE File command now lets you set any BC.EXE compiler option
   in the "Additional Options:" field.

Software Corrections
--------------------

For a list of known problems with BASIC PDS 7.00 (or QuickBASIC 4.50)
that are corrected in BASIC PDS 7.10, query on the word "fixlist7.10".

======================================================================
                              EMAG10-19
    How SUB and FUNCTION Windows Inherit DEFtype in QB.EXE Editor
                         (QuickBASIC, Q47491)

The following information applies to the QB.EXE editor in QuickBASIC
versions 4.00, 4.00b, and 4.50; to the QB.EXE editor in Microsoft
BASIC Compiler versions 6.00 and 6.00b; and to the QBX.EXE editor in
Microsoft BASIC Professional Development System (PDS) versions 7.00
and 7.10.

When creating SUB or FUNCTION procedures in the QB.EXE or QBX.EXE
editor, the procedures inherit the DEFtype statement shown in the
window in which they were first created. DEFtype refers to the
following statements: DEFINT, DEFLNG, DEFSNG, DEFDBL, DEFSTR, and
DEFCUR. (DEFCUR, which is a declaration for the CURRENCY data type, is
supported only in BASIC PDS 7.00 and 7.10.)

If no DEFtype statement is visible in a window, the default DEFSNG A-Z
applies. If a certain range of letters is not covered by a DEFtype
statement in the current window, then that range of letters is covered
by DEFSNG (since single precision is the default data type).

For more information in a related article, query on the following
words:

   DEFLNG and MISMATCH and $DYNAMIC

If the module-level code for the current module contains a DEFINT A-Z
statement, any SUB or FUNCTION created in that module automatically
has a DEFINT A-Z statement placed just above the SUB or FUNCTION line.

If a SUB or FUNCTION is created and moved to a module (source file)
with a different DEFtype than the module it was created in, the
SUBprogram and its new module have different default variable types,
and SHARED or passed variables may not be recognized in the
SUBprogram. In this case, the variables that were intended to be
SHARED may have the same name in both the SUBprogram and the module,
but the variables are of different types and, thus, are considered
different variables. You may encounter this same situation if you
create a SUBprogram (which "inherits" the module-level DEFtype) and
then change the DEFtype at the module level.

To avoid problems accessing SHARED or passed variables, you can either
append the appropriate type-specifier character (%, &, !, #, or $) to
the variable name, or make sure that all your SUBprograms have the
same DEFtype as the module that calls them.

Code Example
------------

Executing the following code prints the values 0 and 10, whereas you
may have wanted 10 and 10. The reason for the difference is that while
Y% is always an integer variable (the "%" type specifier ensures this)
and, thus, is recognized as the COMMON SHARED variable Y% in the
subprogram, "X" is an integer (because of the DEFINT) at the module
level, and a double-precision variable (because of the DEFDBL before
the SUB) in the SUBprogram. Thus, Y% is recognized as SHARED and
changed correctly, while X is considered a local variable in the
SUBprogram and the COMMON SHARED variable X remains unaltered.

   'Module-level code:
   DEFINT A-Z
   COMMON SHARED X, Y%
   CALL thesub
   PRINT X, Y%
   END

   'SUBprogram level in same module -- different DEFtype statement:
   DEFDBL A-Z
   SUB thesub
     X = 5
     Y% = 10
   END SUB

======================================================================
                              EMAG10-20
        Description of Stub Files and How They May Enlarge EXE
                       (BASIC Compiler, Q62908)

The stub files provided with Microsoft BASIC Professional Development
System (PDS) versions 7.00 and 7.10 for MS-DOS should be used only
under specific circumstances. If used incorrectly, linking with the
stub files may actually increase the size of the executable file.

A file in the Software/Data Library explains when to link with stub
files, the effects of each of the stub files, and when linking each
stub file may increase or decrease the size of a program. This file
can be found in the Software/Data Library by searching on the word
STUB700, the Q number of this article, or S12609. STUB700 was archived
using the PKware file conversion utility.

Please see the file mentioned above in the Software/Data Library for
more specific information about when to use the following BASIC PDS
7.00 and 7.10 stub files:

   NOCGA.OBJ, NOEGA.OBJ, NOOGA.OBJ, NOHERC.OBJ NOVGA.OBJ NOGRAPH.OBJ
   NOCOM.OBJ, NOLPT.OBJ
   SMALLERR.OBJ
   87.LIB
   NOEVENT.OBJ
   NOEMS.OBJ
   OVLDOS21.OBJ
   NOFLTIN.OBJ
   NOEDIT.OBJ
   TSCNIONR.OBJ
   TSCNIOFR.OBJ
   TSCNIONP.OBJ
   TSCNIOFP.OBJ
   NOTRNEMR.LIB
   NOTRNEMP.LIB
   NOISAM.OBJ

Most stub files are useful only when you are compiling for use with
BCL7nxxx.LIB (compiling with BC /O) or making a customized run-time
module. When you compile for use with the default BRT7nxxx.EXE run-
time module, the support for BASIC language features is already built
into the run-time module and cannot be stubbed out without rebuilding
(customizing) the run-time module itself. (Two exceptions to this are
NOEMS.OBJ and OVLDOS21.OBJ, which affect overlay support in the BASIC
compiled executable .EXE program and don't affect the run-time
module.)

======================================================================
                              EMAG10-21
        Which BASIC Versions Can CALL C, FORTRAN, Pascal, MASM
                         (QuickBASIC, Q35965)

Certain versions of Microsoft QuickBASIC and Microsoft BASIC Compiler
can CALL routines from certain other Microsoft languages (and pass
parameters), depending upon the product version number, as explained
below.

Microsoft BASIC Professional Development System (PDS) version 7.10 can
be linked with Microsoft C PDS version 6.00 or QuickC version 2.50 or
2.51.

The following application note, which can be requested from Microsoft
Product Support Services, is required if you want to perform BASIC
7.10 mixed-language programming with C 5.10, FORTRAN 5.00, or Pascal
4.00:

   "How to Link BASIC PDS 7.10 with C 5.10, FORTRAN 5.00, or Pascal
   4.00" (application note number BB0345)

QuickBASIC 4.50 and BASIC PDS 7.00 (but not earlier versions) can
create .OBJ modules that can be linked with .OBJ modules from
Microsoft FORTRAN version 5.00 and Microsoft QuickC version 2.01.

QuickBASIC versions 4.00b and 4.50, Microsoft BASIC Compiler versions
6.00 and 6.00b for MS-DOS and MS OS/2, and Microsoft BASIC PDS version
7.00 for MS-DOS and MS OS/2 create .OBJ modules that can be linked
with .OBJ modules from the following languages:

1. Microsoft Pascal version 4.00
2. Microsoft FORTRAN version 4.10
3. Microsoft C version 5.10 and QuickC versions 1.01 and 2.00
4. Microsoft Macro Assembler (MASM) version 5.00 or later recommended,
   but earlier versions should also work

For more information on interlanguage CALLing between Microsoft C and
BASIC, query on the word "BAS2C".

For more information on interlanguage CALLing between Microsoft MASM
and BASIC, query on the word "BAS2MASM".

For more information about using the CALL statement to pass parameters
from BASIC to other languages, query on the following words:

   CALL and (PASSING or PASS) and [language name]

QuickBASIC 4.00
---------------

QuickBASIC version 4.00 creates .OBJ modules that can be linked with
.OBJ modules from the following languages (Microsoft has performed
successful interlanguage test suites for QuickBASIC version 4.00 with
these language versions):

1. Microsoft C version 5.00, QuickC version 1.00
2. Microsoft FORTRAN version 4.00
3. Microsoft Pascal version 4.00
4. Microsoft Macro Assembler (MASM) versions 4.00 and later
   recommended, but earlier versions should also work

Note that QuickBASIC version 4.00b might link with these earlier
language versions, but Microsoft cannot guarantee success because the
4.00b test suites were performed only on the later language versions
mentioned further above in this article.

QuickBASIC 1.x, 2.x, 3.00
-------------------------

In QuickBASIC versions 1.00, 1.01, 1.02, 2.00, 2.01, and 3.00, you can
link only to .OBJ modules from Microsoft Macro Assembler (versions
1.2x, 2.x, or later) or the given version of QuickBASIC. In other
words, QuickBASIC versions 3.00 and earlier can CALL only QuickBASIC
subprograms or assembly routines.

Important Information About Interlanguage CALLing
-------------------------------------------------

To be compatible with compiled BASIC, programs should be assembled or
compiled using the medium, large, or huge memory model, and BASIC must
be linked first (as the main module).

When you link compiled BASIC to other compiled BASIC modules, compiler
versions should not be mixed. For example, an .OBJ module compiled in
QuickBASIC version 4.00 should not be linked with an .OBJ module
compiled in QuickBASIC version 4.00b or 4.50 or Microsoft BASIC
Compiler version 6.00 or 6.00b or Microsoft BASIC PDS version 7.00 or
7.10.

As an alternative to the CALL statement for interlanguage invocation,
you may use the SHELL statement to invoke most (non-TSR) .EXE, .COM,
or .BAT programs that you can also invoke from DOS. SHELL works
differently than CALL. SHELL invokes another copy of the DOS
COMMAND.COM command processor before running a requested executable
program.